Protocol Buffers
https://raw.githubusercontent.com/vscode-icons/vscode-icons/master/icons/file_type_protobuf.svg
通信や、永続化での利用を目的としたシリアライズフォーマット。
XML的ではあるが、より小さな仕組みで、処理が早く、シンプルであることが特徴。 元は Google のインデックスサーバーのリクエスト/レスポンスのプロトコルを処理するために作成されたもの。Protocol Buffer が誕生するまでは API のバージョニングの管理などを含め手動で行っていたため非効率であったということらしい。
公式ドキュメントの OverView によればGoogle社内のAPIの共通言語となっており、30万以上の定義ファイルが活用されているとのこと。
最新のバージョンは v3。
サンプルコードを読み解く
以下は、公式のサンプル。(Scrapbox が Highlight に対応してない) code:サンプル.proto
syntax = "proto3";
message Person {
required string name = 1;
required int32 id = 2;
optional string email = 3;
enum PhoneType {
MOBILE = 0;
HOME = 1;
WORK = 2;
}
message PhoneNumber {
required string number = 1;
}
repeated PhoneNumber phone = 4;
}
syntax = "proto3"; は v3 の宣言。これがない場合は v2 として解釈される。実質的に新規開発においては必須の記載。
サンプルでは message Person というメッセージの形式を定義している
他にも service などの定義が存在する
required optional は入力値の必須か任意かの指定
string int32 などのデータ型もここで定義され、enum も独自に定義できる
特徴的なのはフィールド末尾の = 1 の指定
これは、「タグナンバー」とよばれ、シリアライズにはこの値が使用される。
時間を通して、タグナンバーはメッセージ中で普遍かつ一意である必要がある。
なぜ Protocol Buffer を使うのか？
例としてXMLと比較すると、以下のようなメリットが有る。 シンプルである
3〜10倍程度記載量が少ない
XMLよりはJSON的な構造なので記載量が圧倒的に少ない 20〜100倍程度処理が早い
「処理が早い」というのは文字列の処理を行う際の効率が良く、型検証や、APIのクライアントやサーバー実装の雛形生成にかかる処理が早いということだと思われる 基本的に文字列操作はすごく重い処理であるということを忘れてはいけない
比較して曖昧さが少ない
JSON Schema と比較してどうなのか？
XMLと比較した時JSONはシンプルで良い仕組み
JSON Schema は頑張っているが、元がデータを表す構造以上の仕組みを持たないのでそれをスキーマ言語として活用したときに、本当に見やすいかといわれると難しいものがある
そこで、JSONのようなシンプルさを持ちつつも IDL として設計された Protocol Buffer を使えば、読みやすくかつ、シリアライズように設計されてるので静的解析やデータ型の検証などにも無理なく使えて便利
ということらしい。
参考